AWS Outpostsのデータ保護について確認してみた #reinvent
中山(順)です
これまで普通にAWSを利用していた場合、データの保護はデータの分類やアプリケーションレイヤーでのユーザー認証やアクセス制御 / ネットワークアクセス制御 / アプリケーションの脆弱性管理など比較的上位のレイヤーで考えるものでした。 しかし、Outpostsは自社のサイトに設置するため物理レイヤーにおける保護についても考慮する必要があります。
この記事では、Outpostsを利用するにあたりAWS側でどこまでデータ保護について考慮しているのか・ユーザー自身で考慮するべき部分が何かを整理していきたいと思います。
AWSによるシステム運用中のデータ保護
システムを運用すれば、当然データが発生します。 そのデータはどこかに保存されたり転送されたりします。
それらのデータはどのように取り扱われているのでしょうか? Outpostsのデータ保護については以下のドキュメントに記載されています。
Data Protection in AWS Outposts
データの保存
まず、OutpostsではEBSボリュームを作成することができます。 これにより、データの永続化が可能です。
Outposts上で作成されるEBSボリュームは、以下の通りデフォルトで暗号化されています。 これにより、仮にディスクが持ち出された場合でも復号のための鍵がなければデータを読み出すことができません。
With Outposts, encryption is enabled by default.
Encryption at Rest
データの転送
サーバー間でのデータの送受信はどうでしょうか。
OutpostをAWS間のデータの送受信は暗号化されています。
AWS encrypts in-transit data between your Outpost and its AWS Region.
Encryption in Transit
ただし、ローカルネットワーク上のサーバーとの通信はユーザーの責任で暗号化等で保護する必要があります。
Use an encryption protocol such as Transport Layer Security (TLS) to encrypt sensitive data in transit through the local gateway to your local network.
Encryption in Transit
リソースの削除・停止
Outpost上に作成されたEC2インスタンスを停止させたとき、メモリ上のデータがスクラブされることが明記されています。 また、EBSボリュームで利用されていたブロックもリセットされることが明記されています。
When you stop or terminate an EC2 instance, the memory allocated to it is scrubbed (set to zero) by the hypervisor before it is allocated to a new instance, and every block of storage is reset.
Data Deletion
ハードウェア保守
システムを運用していれば当然ハードウェアは故障します。 その際、どのように復旧させるのでしょうか。
Outpostsでは、現地で修理するようなことはなく、交換対応することが明記されています。
When the AWS installation team arrives on site, they will replace the unhealthy hosts, switches, or rack elements and bring the new capacity online. They will not perform any hardware diagnostics or repairs on site.
Hardware Maintenance
その際、交換されたハードウェア上のセキュリティキーやデータが残っている可能性のあるハードウェア(SSDドライブ?)を破砕することが明記されています。
If they replace a host, they will remove and destroy the NIST-compliant physical security key, effectively shredding any data that might remain on the hardware. This ensures that no data leaves your site.
Hardware Maintenance
ユーザーが責任を負うべき範囲
このように、AWSが提供する機能やオペレーションでかなり高度なデータ保護が提供されていることが確認できます。 とは言っても、設置場所が利用者のサイトのため利用者の責任で対策するべき点はあります。 具体的には以下のような点が挙げられています。
- Outpostの機器が設置されてから撤去されるまでの物理セキュリティ
- 設置環境へのアクセス制御および保守要員の教育
- データ管理ポリシーの策定と実施
- OutpostとAWS間のネットワーク接続の維持
- ローカルネットワークとOutpostのLocal Gateway間の通信の暗号化
- Physical and environmental security of the Outpost, starting from the moment that the Outpost equipment arrives at your facility to the point at which the Outpost equipment is removed at the end of the term or for repairs.
- Physical access controls around the Outpost equipment at your facility. This includes background checks and security training for facility staff.
- Data management policies, including terminating EC2 instances and deleting data volumes before the Outpost equipment is removed at the end of the term or for repairs.
- Configuring and maintaining a network connection between the Outpost and the AWS Region. Communication sent over this connection between the Outpost and the Region is encrypted by AWS.
- Encrypting any traffic traveling over your network to the local gateway.
これ以外にも、従来通りIAMやSecurity Group等の適切な管理やEC2等におけるパッチ管理やアプリケーションの管理はユーザー側の責任でセキュアに保つ必要があります。
まとめ
AWSがコントロール可能な範囲においては、セキュリティの基本である多層防御の考えがきちんと実装されていることが確認できました。
リソースを停止したり削除することでデータはリセットされるため、利用者が適切にAWSリソースの管理を行うことでデータの削除をコントロールすることができます。 また、ハードウェア保守で交換される際にデータが保存されている可能性のあるデバイが適切に破棄されます。 さらに、EBSボリュームはKMSで暗号化まで行われています。 ここまでやっていれば、物理レイヤーからのデータ漏洩の可能性はかなり低減できているのではないかと思います。
もちろん、将来にわたってゼロであるとは思っていません。 利用者は利用者自身の責任範囲で適切な管理をしつつ、AWSの運用要員(配送・ハードウェア保守要員など)が仕様通りの適切な振る舞いをしているか作業の折に確認することも重要かと思います。 そういった確認を通じてAWSが「信頼」できるサービスプロバイダーであるか評価し、フィードバックし続けることも重要ではないかと思います。
現場からは以上です。